Method for performing cryptographic functions in a computer application, and application adapted to the implementation of said method

ABSTRACT

A computer application is provided with a cryptographic toolbox with having a modular architecture. The toolbox has a module for manipulating data formats used in the performance of cryptographic functions, a module for executing algorithms involved in cryptographic operations, a module for accessing cryptographic resources, and a functional module supervising the data format manipulation, algorithm execution and cryptographic resource access modules. The functional module has a functional interface with the rest of the application.

The present invention relates to the use of cryptographic techniques bycomputer applications.

It aims to offer application security services to various applications,in particular to applications written in a mobile code language (MCL forshort) and running on various computer platforms. These applicationsecurity services may require access to various types of cryptographicresources (CR for short) contained in varied cryptographic media. Thusthe aim is to be able to access these CRs through an architecture thatis open and ready for the evolution of the techniques employed,particularly of the platforms, the cryptographic methods (algorithms,key sizes, etc.), the cryptographic media and standards, the applicationsecurity services, the applications relying on these applicationsecurity services, etc.

Amongst the applications covered by the invention, mention can be madefor example of the tele-procedure, workflow, email and documentpublication applications etc.

By being written in a mobile code language, they can be independent ofthe platform on which they run. This language may for example be:

-   -   Java (see “The Java Language Specification” published by Sun        Microsystems, Inc.);    -   CaML (see http://caml.inria.fr/);    -   C# (see “C# Language Specification” published by Microsoft        Corporation); etc.

The expression “computer platform” refers to the hardware and softwareenvironments suitable for supporting the execution of the applicationsin MCL. The platforms concerned are for example:

-   -   computers equipped with the “Windows” operating system from        Microsoft Corporation (version 95/98/ME/NT/2000/XP) and an        “Internet Explorer” browser from Microsoft Corporation or        “Netscape Navigator” from Netscape Communications Corporation;    -   computers equipped with the MacOS 8/9/X operating system from        Apple Computer, Inc. and an “Internet Explorer” or “Netscape        Navigator” browser;    -   “Sun Solaris” platforms from Sun Microsystems, Inc. furnished        with a “WebSphere” type server from International Business        Machines Corporation; etc.

The application security services that are being offered to theapplications are for example electronic signature, electronic signatureverification, encryption, decryption, timestamping, timestampverification, secure protocol and authentication services etc. They usevarious types of CR such as cryptographic keys, certificates, algorithmsallowing them to be used, etc.

The cryptographic media may be of the smart card type, a module able tobe connected to a USB (“Universal Serial Bus”) port called “USB token”,a crypto-hardware card, a PCMCIA (“Personal Computer Memory CardInternational Association”) card, a software store, etc.

There are numerous cryptographic standards concerning cryptographicalgorithms, key generation, the format of messages of a cryptographicnature, secure protocols, etc.

The two most widely used signature algorithms with public key are RSA(“Rivest Shamir Adelman”) and DSA (“Digital Signature Algorithm”). TheRSA may also be used for encryption. The RSA is the subject of astandard known as PKCS#1 (Public Key Cryptography Standard No. 1”)published by RSA Security, Inc. The most used hashing algorithms areSHA-1 and MD5. The best known secret key algorithms are DES (“DigitalEncryption Standard”), Triple DES, AES (“Advanced Encryption Standard”),IDEA (“International Data Encryption Algorithm”), CR4, KASUMI and MISTY.

The most widely used formats for signed messages are:

-   -   PKCS#7, published by RSA Security, Inc. and by the Internet        Engineering Task Force (IETF) as RFC 2315, which has been        adopted in CMS (“Cryptographic Message Syntax”, see RFC 2630 of        the IETF), these standards being used particularly in the S/MIME        (“Secure Multipurpose Internet Mail Extensions”) specification        for signed emails;    -   PGP corresponding to the signed messages originating from the        PGP (“Pretty Good Privacy” marketed by Networks Associates        Technology, Inc.) software and its equivalents;    -   XML-DSig, forming part of the family of XML (“extended Markup        Language”) data formats.

The most widely used formats for encrypted messages are PKCS#7/CMS andPGP.

For access to cryptographic resources (CR), there are high levelinterfaces and low level interfaces. The high level interfaces, inparticular PKCS#11 and CAPI, offer a level of abstraction relative tothe medium of the cryptographic elements managed.

PKCS#11 is a public standard and free to use, published by RSA Security,Inc. It describes an application programming interface (API) allowinglow level cryptographic operations such as the generation and storage ofkeys, the electronic signature, the encryption and decryption of data,etc. However, PKCS#11 does not mutualize the CRs between the differentapplications that make use of it. PKCS#11 does not manage the trustcertificate chains. It cannot be invoked from mobile code languages.This interface is used particularly in “Netscape Navigator” in order toopen the cryptographic functionalities of the navigator and of themessaging client to third party suppliers. This interface is alsoemployed in most products that require this same openness. The majorityof cryptographic hardware suppliers offer a PKCS#11 module for accessingtheir products.

CAPI (“Crypto API”) is an API developed by Microsoft Corporation andavailable only on the “Windows” platforms. It offers applicationsecurity functions and functions of signature verification and ofmanagement of trust certificate chains absent from PKCS#11. CAPI is notopen-ended and cannot be used to add functions such as timestamping ornew protocols. CAPI carries out mutualization of the CRs to which it hasaccess between the applications which make use of it. But it cannotgenerally be invoked from the mobile code languages. A cryptographicmodule interfacing in CAPI in order to offer security services is calleda CSP (“Crypto Service Provider”). To be usable via CAPI, the CSPs mustbe signed electronically by Microsoft Corporation which for thisrequires access to the sources of the CSP. The major suppliers ofcryptographic hardware usually offer a CSP for accessing their product.

Other interfaces for accessing CRS exist at a lower programming level,that is to say offering less abstraction relative to the CRs managed.

Each hardware cryptographic medium possesses a set of basic instructionsto which it can respond. These instructions, sent directly over theconnectors of the medium, are used to perform the basic cryptographicoperations. Usually these basic instructions are not public, or at leastnot documented.

The PC/SC (“Personal Computer/Smart Card”) standard aims to offer a verylow level of abstraction relative to these instructions, in order thatcommunication between the workstation and the cryptographic medium (forexample the smart card) is performed according to a set of instructionscommon to all the cryptographic media. Most of the CSPs and PKCS#11modules rely, for their low interface, on PC/SC. Each cryptographicmedium usually possesses a PC/SC driver which is invoked in the CSPs orin the PKCS#11 modules via the standard PC/SC interface and which isbased on the aforementioned basic instructions. PC/SC providesmutualized access to certain CRs (smart cards, USB tokens) for theapplications which are based on it. But it cannot generally be invokedin mobile code languages and it does not provide high level services.

Software cryptographic media, for their part, are usually stores of keysand of certificates contained in files that have a format that may ormay not be documented. “Netscape Navigator” keeps the cryptographic keysand certificates in two files called cert7.db and key3.db whose formatis stable even on changes of browser version. The known format of thisfile may be a sufficient interface for a service to be able to accessthese keys and certificates. An interface for access to these filesexists on certain platforms, particularly NSS (“Netscape SecurityServices”). It involves proprietary formats.

Mobile code languages (MCL) are programming languages whose resultantcode is not dependent on one microprocessor or on one operating system.To run, the program needs to find a similar execution environment on thevarious computers on which it is required to run.

The MCLs that are of primary interest are those that are used also toproduce web applications. The most widely used is the Java language fromSun Microsystems, Inc. Java web applications running in a browserenvironment are called applets. Another MCL that has appeared morerecently is the C# language from Microsoft Corporation. The example thatwill be more particularly considered in the present application is thatof Java, but the concepts apply to any other MCL. They may also beapplied to a program written in a language other than an MCL.

MCLs may propose cryptographic interfaces to the applications. In theJava example, the Java cryptographic architecture (JCA, “JavaCryptography Architecture”) and the Java cryptographic extension (JCE,“Java Cryptography Extension”) play this role in order to be able tomanipulate certificates, keys, algorithms, etc. With Java version 2 the“Trusted API” also appeared which is used to manage trust by means ofpublic key certificates.

An application in MCL may need to access functionalities that are notavailable in its execution environment. If these functionalities areavailable in dynamic library form dependent on the platform, the Javaenvironments can be used to access these resources via specified but notunified interfaces:

-   -   JNI (“Java Native Interface” from Sun Micro-systems, Inc.)        applying to recent browsers;    -   JRI (“Java Runtime Interface” from Netscape Communications        Corporation) applying to certain former versions of “Netscape        Navigator” or on certain platforms;    -   RNI (“Raw Native Interface”) from Microsoft Corporation)        applying only in the “Internet Explorer” browser.

These cryptographic libraries existing in certain MCLs have thedrawbacks of not being either modular or upgradeable, and of not makingit possible to diversify the CR sources.

The techniques mentioned above form disparate bricks in the compositionof secure web applications. Nothing is provided to make them worktogether.

For accessing CRs from a Java applet, the choices are very limited, evennonexistent. A Java applet cannot use the CRs of the browser in which itis running. Nor can it use CRs accessible via a PKCS#11 interface. Asfor the JCA/JCE resources, they are often poorly recognized (or notrecognized at all) in the browsers. Additionally, these JCA/JCEresources, when they are recognized, cannot be mutualized betweenseveral applications. To be mutualizable, a resource must be accessiblevia a standard interface independent of the programming language and ofthe platform.

For the use of the cryptographic standards, the standard formats PKCS#7,PGP, and XML-DSig are not recognized in the MCLs.

The interfaces for accessing CRs are usually insufficient to fullyprovide the security services that are required by the applications thatmay call upon them.

Thus, PC/SC allows only calls to the functions available on the smartcard, which are extremely limited (reading a certificate, having a keysigned, usually). PKCS#11 allows the manipulation of more complexobjects, but provides no function for verifying certificate trustchains, and does not include complex functions such as timestamping orcalls to communication protocols. CAPI allows the verification of trustchains but handles neither the OCSP protocol (“Online Certificate StatusProtocol”, RFC 2560, IETF) nor timestamping (see RFC 3161, IETF).

In these conditions, each program requiring the call to these CRs mustin itself implement the chaining logic of the elementary securitybricks, which considerably increases the cost of development.Furthermore, it generates risks of security failure in the developedapplication.

In addition, the implementations of the various most widely usedinterfaces are still not identical from one manufacturer to another,which requires each application to be adapted to each CR supplier. Forexample, a service that operates with a USB token of supplier A will notbe able to operate with that of supplier B if the implementations of thePKCS#11 interface produced by both of them differ.

The CRs are of different natures on the station, accessible viaextremely varied interfaces. For reasons of complexity and cost, theapplications usually implement only one type of interface, thus closingaccess to the other CRs.

Though it is useful to diversify the cryptographic technical or standardfunctions implemented within a given application, the resultingdevelopment load may become considerable. This is all the morepenalizing as the person developing such an application is not usuallyan expert in cryptography, but rather in the field (subject) to whichthe application in question pertains. The security solutions in the MCLsimplemented hitherto are very sensitive overall to any upgrade in thestandards, formats, sizes of keys, algorithms, etc.: a modification ofone of these aspects requires reconsideration of all the sources, or atleast of a substantial part of these sources which, as a general rule,is not well isolated and identified in advance.

An aim of the present invention is to overcome the above problems to alarge extent.

The invention thus proposes a method for performing cryptographicfunctions in a computer application, characterized in that theapplication is provided with a cryptographic toolbox with modulararchitecture comprising:

-   -   a module for manipulating data formats used in the performance        of cryptographic functions;    -   a module for executing algorithms involved in cryptographic        operations;    -   a module for accessing cryptographic resources; and    -   a functional module supervising the data format manipulation,        algorithm execution and crypto-graphic resource access modules,        and having a functional interface with the rest of the        application.

This modular architecture of the application security services hasnumerous advantages for the developer of applications, in particular ofapplications in MCL. It can thus be used to combine the cryptographicfunctions in a toolbox upon which the developer, who is not necessarilyan expert in cryptography, may call according to his requirements whileusing the functional API.

Furthermore, this architecture lends itself quite easily to theevolutions of cryptographic technology. In order to take account of newdata format standards, it will usually be sufficient to update simplythe data format manipulation module. In order to take account of newcryptographic algorithms, it will usually be sufficient to update simplythe algorithm execution module. In the event of changes to the methodsof access to the CRs; it will generally be sufficient to update thesingle module for accessing the CRs. Here again, these various changesmay be made without having to be monitored by the developers of theprograms. To take account of new security functions on the functionalAPI, it will often be sufficient to update the functional module.

The aforementioned modules of the cryptographic toolbox may besupplemented by a utilities module that can be invoked by each of theother modules and given the task in particular of managing specificcharacteristics of the execution platform running the application. Ifchanges of platform require updates of the application, the latter mayusually, as concerns the cryptographic toolbox, be limited to thisutilities module.

Another aspect of the present invention relates to a computerapplication comprising a cryptographic toolbox having the modulararchitecture mentioned above.

Other particular features and advantages of the present invention willappear in the following description of nonlimiting exemplaryembodiments, with reference to the appended drawings, in which:

FIG. 1 is a block diagram of a computer platform suitable for running anapplication in MCL according to the invention;

FIGS. 2 and 3 are block diagrams of applications in MCL operatingaccording to the invention.

With reference to FIG. 1, a system equipped in accordance with theinvention comprises a computer platform 1 suitable for runningapplications 2 written in mobile code language (MCL). Various types ofplatforms and MCL, such as those mentioned above, may be employed. Inthe example illustrated by FIG. 1, the platform 1 is equipped withseveral sources 3 of cryptographic resources (CR) each having a specificAPI 4 for accessing the CRs. These APIs 4 may be of the same nature (forexample PKCS#11, CAPI, PC/SC, etc.) or of different natures.

To interact with the security functions of applications 2 written inMCL, the platform 1 is provided with a mutualization API 5 implementedby a resident translation program 6 called a “bridge”. This bridge 6 isplaced between the mutualization API 5 and the APIs 4 for accessing theCR sources 3. If the program 2 runs within a browser, the mutualizationAPI 5 must respect the interface format with this browser (JNI, JRI orRNI if the MCL is Java).

When the platform 1 is started up, or the first time it is invoked by aprogram 2, the bridge 6 sets up communication sessions with each of theCR sources 3 via their respective access interfaces 4. It then maintainsthese active sessions. It relays the instructions from the mutualizationAPI 5 to the CR sources. These instructions are not addressed to oneparticular CR source, but to all these sources of which the bridge 6supplies a general, abstract vision. The bridge retrieves the responsesone by one from the CR sources and, depending on the context, relaysthem in-return to the application 2 via the mutualization API 5.

Usually, an application 2 which needs cryptographic resources begins bytransmitting over the API 5 a command to search for cryptographicidentification data, these data typically taking the form of an X.509certificate (see RFC 2459 published by the IETF). In response to thiscommand received over the API 5, the bridge 6 interrogates each CRsource 3. The certificates returned by the sources 3 over their accessAPIs 4 are analyzed by the bridge 6 which filters them in order toconstruct the response returned to the application via the mutualizationAPI 5. Then, the application 2 addresses a cryptographic operationcommand to the bridge 6 via the mutualization interface 5, specifyingthe certificate corresponding to the CRs to which it is required to makea call, obtained in the response to the preceding search command. Thebridge 6 then directs this cryptographic operation command to the CRsource that supplied this certificate by carrying out the translationsnecessary to move from the mutualization API 5 to the correspondingaccess API 4. The result of the cryptographic operation returned by theCR source 3 will then be relayed by the bridge 6 to the application 2via the mutualization API 5.

For example, if the program 2 has to carry out an encryption operationof the PKCS#1 type, it begins by questioning the bridge 6 so that itsupplies it with the corresponding certificates it has at its disposal.The bridge 6 obtains a list of certificates from the sources 3 anddetermines which of them match the request of the application and willbe the only ones supplied to the application. The latter selects acertificate (if there are several) then requests execution of theencryption operation via the API 5 by supplying the message to beencrypted and the random number to employ. The bridge 6 relays thiscommand to the appropriate source 3 then returns on the API 5 theresponse received on the API 4.

All this is done without the application 2 knowing the source 3 thatwill be operative nor even the nature of its access interface 4. It istherefore not necessary for the developer of the applications in MCL 2to take account of the specifics of the different types of CR sources.

FIG. 2 shows a preferred architecture of the security services in anapplication 2 written in MCL. In a known manner, these services are forexample the electronic signature, the electronic signature verification,the encryption, the decryption, the timestamping, the timestampingverification, the instances of secure protocols, the authentication,etc.

These services are supplied within the application in MCL 2 by means ofa cryptographic toolbox 10 whose software architecture is modular. Itwill be noted that the modules 11-15 are not necessarilycompartmentalized for reasons of implementation volume.

The cryptographic toolbox 10 comprises:

-   -   a functional module 11;    -   a module 12 for accessing the cryptographic resources;    -   a primitives module 13; and    -   a data format manipulation module 14.

In FIG. 2 (as in FIG. 1), the orientation of the arrows indicates thedirection in which the modules 11-14 are called.

A utilities module 15 preferably supplements these four modules 11-14.This utilities module 15 may be called by any one of the other modules11-14 of the toolbox 10. The utilities module 15 is responsible for thefollowing functionalities:

-   -   managing the differences between the platforms 1 and the        specifications of the MCL and the specifics of the operating        system used in these platforms;    -   manipulating the different possible forms of encoding (for        example conversions between binary, Base64, PEM, etc.);    -   where appropriate, managing the logging, the self-installation        of the toolbox 10, its updating, etc.

The data format manipulation module 14 allows the manipulation of dataand cryptographic messages in standard formats such as for examplePKCS#7/CMS, PGP, XML-DSig, X.509 certificates, X.509 revocation lists(CRL, “Certificate Revocation List”), OCSP, etc. by in particular beingused for their encoding and their decoding. This module 14 is preferablystandalone, that is to say that it does not need to make calls to theother modules 11-13.

For example, for the standards originating from the working group on thepublic key infrastructures of the IETF (PKIX) whose data formats aredescribed in ASN.1 (“Abstract Syntax Notation No. 1”), the data formatmanipulation module will understand one or more ASN.1 encoders/decodersand the types described in PKIX.

The primitives module 13 includes:

-   -   cryptographic algorithms, particularly the hashing algorithms,        random number generation algorithms, all the algorithms using        public keys, etc.;    -   certificate and revocation management algorithms;    -   data types allowing the manipulation of the keys and        certificates (containing these keys and certificates or        containing a reference to these keys and certificates). For        example, if a private key is contained in a smart card which it        may not leave, the “key” type is used to have the operations        requiring the use of that key carried out by the smart card and        to retrieve the result of these operations.

It is desirable that the writing of the code of this primitives module13 should depend only on the data format manipulation module 14 that itcan invoke.

The module 12 is used for accessing CRS (for example keys orcertificates) that may be of two types:

-   -   internal CRS, that is to say directly accessible in the MCL (for        example: keys and certificates managed directly by the program        2). These resources can for example be read by the program on a        local disk storage unit 20;    -   external CRs, that is to say accessible via the mutualization        API 5 (for example: keys and certificates on a smart card or        managed by a browser).

From the point of view of the functional module 11 that calls it, themodule for accessing the CRS 12 is used to disregard the type of CR andthe interface for accessing these CRS. Thanks to this, the program maymanipulate the CRS without necessarily knowing their medium.

In the embodiment illustrated in FIG. 2, the CRs can be accessed eithervia the mutualization API 5 described with reference to FIG. 1, which isimplemented by a submodule 12 a of the module 12 (external CRs), ordirectly in the MCL by means of a submodule 12 b of the module 12(internal CRs). It should be noted that the submodule 12 b for accessingthe internal resources is optional.

Excluding the cryptographic toolbox 10, the rest of the program (applet16 in the example illustrated in FIG. 2) is written in MCL by adeveloper who is not a specialist in cryptography. The functional module11 presents to this applet 16 an interface 17 called “functional API”which performs the general security functions algorithm while relying onthe modules 12-14. The security functions thus offered by the functionalAPI are for example electronic signature, verification of electronicsignature, encryption, decryption, timestamping, timestampingverification, secure protocols, authentication, etc.

Depending on the case, these functions may have parameters that are usedto modify a standard behavior. For example, the electronic signaturefunction allows the possibility of returning signed data in the PKCS#7or XML-DSig formats. Another example: the signature verificationfunction gives the possibility of checking or not checking thecertification trust chain with or without revocation control.

As an illustration, the assumption hereinafter is the situation of aJava applet running in a “Netscape 4” browser in the “Windows”environment in order to produce one or more electronic signatures inPKCS#7 format. This embodiment corresponds to the need to use securityfunctions based on a Java applet running in the Java virtual machine of“Netscape 4”. These browsers support a limited version of version 1.1 ofthe Java platform specifications. In particular, they do not support thestandard Java security functions.

The method of mutualizing access to the CRs from Java is then carriedout by a bridge 6 which conforms with the JRI interface with thebrowser. The bridge federates one or more sources 3 conforming with thePKCS#11 type access interface of which it supplies a general, abstractvision. To access the software keys and certificates managed internallyby “Netscape Navigator” and available in the form of files (calledcert7.db and key3.db in the “Windows” operating systems), the CR source3 corresponding to these files presents a PKCS#11 type access interface4 dedicated to accessing these resources. The bridge 6 manages a PKCS#11session with each CR source 3 in a manner transparent for the program 2.

In this example, the application security functions are constructedaccording to the architecture in FIG. 2. The data format manipulationmodule 14 implements the X.509 (certificates and CRL) and PKCS#7 (signedand/or encrypted messages format) standards. The primitives module 13implements the hashing algorithms MD5 and SHA-1. The module 12 foraccessing the CRs performs the access via the mutualization API 5 byinteracting with the bridge 6. Finally, the functional module suppliesin its functional API 17 the signature function, of which an exemplaryinterface in Java language is given below: public classSignatureFunction   // Initialization of the signature   publicSignatureFunction (byte[ ] dataToSign) {..}   public SignatureFunction(byte[ ] dataToSign, boolean detached) {..}   public voidsetDetachedSignature (boolean detached) {..}   public voidsetSameCertificateAcceptance (boolean accept) {..}   // Signatureiteration, in order to add a signature   // (allows cosignature)  public void setHashAlgorithm (String hashAlgorithm) {..}   public voidsetWithCertificateChain (boolean include) {..}   public voidsetWithAuthenticatedAttribute (boolean include) {..}   public voidaddAuthenticatedAttribute (..) {..}   public voidsetWithunauthenticatedAttribute (boolean include) {..}   public voidaddunauthenticatedAttribute (..) {..}   public void setHashAlgorithm(String hashAlgorithm) {..}   public void sign ( ) {..}     // Selectionof the certificate   public CertificateListFunction getCertificateLister( ) {..}   public void setcertificateListFunction      (UserCertificateListerFunction certLister) {..}   publicCertificateSelector getCertificateSelector ( ) {..}   publicsetcertificateSelector (Certificateselector selector) {..}  // Parameter of the signature ergonomics   public setSignConfirmer(CertificateConfirmer confirmer) {..}     // effective for PKCS#11 only:  public setReenterPINCode (boolean reenter) {..}   // Finalization  public ASN1Object getASN1Signature {..}   public byte[ ]getBinarySignature {..}   public String getBase64Signature {..}   publicString getPEMSignature {..}

The applet 16 calls these security functions defined by the functionalAPI 17. In most cases, the SignatureFunction, Sign and getPEMSignaturefunctions may be sufficient to successively initialize, execute andretrieve the digital signature. The other functions are used to enrichthe functional API 15 for the applets that require it.

It will be noted that many variants may be applied to the previouslydescribed exemplary embodiments.

For example, the bridge 6 may interact only with a single accessinterface 4, even to a single CR source 3, for example a single type ofsmart card.

The invention is not dependent on the operating system or the webbrowser employed. Neither does it depend on the type of interfacebetween Java and the browser nor on the interfaces for accessing theCRs. It may in particular rely on RNI and CAPI in the case of an“Internet Explorer” browser from version 4 onwards.

For “Netscape 6” browsers, which support at least version 1.3 of theJava platform specifications, the method of mutualizing access to theCRs from Java is carried out by a bridge 6 which conforms with the JNIinterface with the browser. The bridge federates one or more modulesconforming with the access interface of the PKCS#11 type in the samemanner as for the Netscape 4 browsers. However, the files containing thecertificates and keys managed by Netscape 6 are situated in anotherlocation on the hard disk.

The invention is also applicable to standalone Java programs, that is tosay independent of any browser. The invention is then used essentiallyin the same manner as in the case of the “Netscape 6” browser. Thestandalone applications, run in a Java virtual machine, make use of thefunctional API 17.

For applications on server, the bridge 6 and the toolbox 10 are similarto those that can be used with the “Netscape 6” browsers. However, theenvironment is not that of a browser, but of a “servlet” engine such asfor example “Tomcat” from the Apache Software foundation, or“WebSphere”. The Java programs that make use of the functional API 17are servlets running in the Java virtual machine of the engine, and notapplets.

In the server-based applications, it is common for the CRs to bedirectly accessible by the program written in Java. They may for examplebe stored internally in the execution platform for running the programor on an external medium exhibiting an interface compatible with theMCL. In this case, which is not necessarily reserved for the servers,the module for accessing the CRs of the cryptographic toolbox may notexhibit the submodule 12 a exhibiting the mutualization interface 5.

FIG. 3 illustrates such an embodiment. The cryptographic toolbox 10′available to the servlet 16′ is essentially the same as that representedin FIG. 2. The module 12′ for accessing the internal CRs exhibits thesame interface with the function module 11. It directly accesses the CRsof key or certificate type in the storage unit 20. The algorithmicresources are in this case provided in the program 2 by the primitivesmodule 13. If an algorithmic processing is requested of the module 12′by the functional module 11, the former provides the input data thereof(depending on the case keys read from the memory 20, messages, time,random numbers, etc.) to the primitives module 13. The module 12′recovers the result of this processing and transmits it to thefunctional module 11 as if it originated from a mutualization API.

The previously described examples in the case of Java can be transposedto any MCL supported, depending on the case, in the browsers, in theservlet engines, or in standalone applications. To benefit from themutualization of the CRs, the MCL must be capable of accessing externalsoftware modules. This is particularly valid for variants of CaML andfor C#.

1. A method for performing cryptographic functions in a computerapplication, provided with a cryptographic toolbox having a modulararchitecture comprising: a module for manipulating data formats used inthe performance of cryptographic functions; a module for executingalgorithms involved in cryptographic operations; a module for accessingcryptographic resources; and a functional module supervising the dataformat manipulation, algorithm execution and cryptographic resourceaccess modules, and having a functional interface with the rest of theapplication.
 2. The method as claimed in claim 1, wherein the module foraccessing the cryptographic resources is devised so as to readcryptographic resources including cryptographic resources directlyaccessible through a language of writing of the application.
 3. Themethod as claimed in claim 2, wherein a part at least of thecryptographic resources read are submitted to the algorithms executionmodule.
 4. The method as claimed in claim 1, wherein the cryptographicresources include cryptographic resources stored in externalcryptographic means comprising at least one cryptographic source havingits own access interface.
 5. The method as claimed in claim 4, whereinthe module for accessing the cryptographic resources cooperates with theexternal cryptographic means by way of a mutualized interfacesubstantially independent of the cryptographic sources and of theirrespective access interfaces.
 6. The method as claimed in claim 1,wherein the cryptographic toolbox furthermore comprises a utilitiesmodule invocable by each of the other modules.
 7. The method as claimedin claim 6, wherein the utilities module is devised so as to managespecific characteristics of an execution platform for running theapplication.
 8. The method as claimed in claim 6 or 7, wherein theutilities module is devised so as to effect conversions between variousdata coding formats.
 9. The method as claimed in claim 6, wherein theutilities module is devised so as to carry out operations ofinstallation or of updating of the cryptographic toolbox.
 10. The methodas claimed in claim 1, wherein said application is written in a mobilecode language.
 11. A computer application comprising a cryptographictoolbox with modular architecture comprising: a module for manipulatingdata formats used in the performance of cryptographic functions; amodule for executing algorithms involved in cryptographic operations; amodule for accessing cryptographic resources; and a functional modulesupervising the data format manipulation, algorithm execution andcryptographic resource access modules, and having a functional interfacewith the rest of the application.
 12. The application as claimed inclaim 11, wherein the module for accessing the cryptographic resourcesis devised so as to read cryptographic resources including cryptographicresources directly accessible through a language of writing of theapplication.
 13. The application as claimed in claim 12, wherein themodule for accessing the cryptographic resources is devised so as tosubmit a part at least of the cryptographic resources read to thealgorithms execution module.
 14. The application as claimed in claim 11wherein the cryptographic resources include cryptographic resourcesstored in external cryptographic means comprising at least onecryptographic source having its own access interface.
 15. Theapplication as claimed in claim 14, wherein the module for accessing thecryptographic resources cooperates with external cryptographic means byway of a mutualized interface substantially independent of thecryptographic sources and of their respective access interfaces.
 16. Theapplication as claimed in claim 11, wherein the cryptographic toolboxfurthermore comprises a utilities module invocable by each of the othermodules.
 17. The application as claimed in claim 16, wherein theutilities module is devised so as to manage specific characteristics ofan execution platform for running the application.
 18. The applicationas claimed in claim 16 wherein the utilities module is devised so as toeffect conversions between various data coding formats.
 19. Theapplication as claimed in claim 16, wherein the utilities module isdevised so as to carry out operations of installation or of updating ofthe cryptographic toolbox.
 20. The application as claimed in claim 11,written in a mobile code language.